home *** CD-ROM | disk | FTP | other *** search
/ Ahoy 1987 July / Ahoy_Magazine_87-07_1987_Double_L_Side_B.d64 / doctor who.txt < prev    next >
Text File  |  2022-10-26  |  7KB  |  243 lines

  1. Doctor Who Data Base
  2.  
  3. by Len Lindsay
  4.  
  5. This disk I wanted to have several
  6. programs demonstrate file handling,
  7. especially with random files. Doctor
  8. Who presented itself as an excellent
  9. topic. This science fiction show has
  10. been on the air for 24 years now,
  11. with a total of over 150 movie length
  12. shows. In each show, the Doctor has
  13. varying companions, and meets
  14. different adversaries (and even
  15. interesting monsters). So, I created
  16. a data base system that can easily
  17. keep track of a series of shows. Very
  18. little in this data base is specific
  19. to Doctor Who (to illustrate this, we
  20. also are including Star Trek data on
  21. the disk). I used 8 fields of 27
  22. characters each to store the data for
  23. a show, plus two extra fields that
  24. you can decide how to use. The titles
  25. for each of the 8 main fields can
  26. vary depending on what information
  27. you wish to keep track of. For the
  28. Doctor Who shows I chose the
  29. following:
  30.  
  31. Show Name:
  32. Doctor: 
  33. Companion1: 
  34. Companion2: 
  35. Companion3: 
  36. Adversary1: 
  37. Adversary2: 
  38. Location:
  39.  
  40. I've also provided two extra "user"
  41. fields. The first is an "ID" of 11
  42. characters. You could put the video
  43. tape number here, the name of your
  44. friend who has this show on tape, or
  45. a short comment on the show. The
  46. other field is only one character. It
  47. can be used to rate each show (A,B,C,
  48. etc). I use it to mark the shows that
  49. I have seen.
  50.  
  51. Since I am a true Doctor Who fan, I
  52. have painstakenly entered all the
  53. data for the first 144 shows! This
  54. large data base of information is on
  55. this disk along with the data base
  56. program itself. Once you have a data
  57. base filled with information, it is
  58. easy and fun to use.
  59.  
  60. For example, let's say your favorite
  61. Doctor Who adversaries were the
  62. CYBERMEN. Using the data base system,
  63. you can choose the Search option, and
  64. it will list every show that included
  65. cybermen as adversaries! The nice
  66. thing about this is that the system
  67. uses COMAL's IN operator to find the
  68. matches. Thus, you can ask the system
  69. to look for CYB and it will find both
  70. CYBERMEN as well as their "pets", the
  71. CYBERMATS. Remember, the search is
  72. very picky on upper or lower case.
  73. Thus, Cyb will not match CYB.
  74. Therefore, you may wish to do as I
  75. did on my data -- never use shifted
  76. letters! (Or always capitalize the
  77. first letter of each word).
  78.  
  79. Since this system uses a random file
  80. for its data, it is easy to randomly
  81. display any show. Just type in the
  82. show number, and instantly (almost)
  83. its information is displayed. To see
  84. the next show just type + (plus
  85. sign). To see the previous show type
  86. - (minus sign).
  87.  
  88. Another nice feature of this system
  89. is BROWSE. It allows you to scan over
  90. all the entries, one after another,
  91. starting after the show currently
  92. displayed. It even has a variable
  93. pause between shows. Five seconds is
  94. the default, but for a fast scan, use
  95. 0 for the length of pause.
  96.  
  97. NOTES ABOUT THE PROGRAM
  98.  
  99. The variable mark$ is used to
  100. determine whether or not the
  101. information display is normal or
  102. reverse field. Near the beginning of
  103. the program you will see this
  104. statement:
  105.  
  106. display(mark$<> " ")
  107.  
  108. DISPLAY is the name of the procedure
  109. that prints the information about the
  110. show to the screen. It has one
  111. numeric parameter. If the parameter
  112. is FALSE (a value of 0) then the
  113. information is displayed normally. If
  114. it is TRUE (a value not equal to 0)
  115. then the information is displayed in
  116. reverse field. Mark$<> " " is a
  117. comparison that will always be either
  118. TRUE or FALSE, thus providing the
  119. proper parameter.
  120.  
  121. Notice that to have the reverse
  122. display, each value printed must be
  123. the correct length because the
  124. reverse field will stop at the last
  125. character. The length used in this
  126. program is 27. Thus, if the show name
  127. is less than 27 characters, I had to
  128. do something to print reverse field
  129. spaces at the end of the name. I let
  130. COMAL take care of this for me by
  131. using substring notation when
  132. inputing this data (from both
  133. keyboard input and file input). For
  134. example:
  135.  
  136. dim name$ of 27
  137. input "name:": name$ 
  138. print chr$(18)+name$ 
  139. print "length is";len(name$) 
  140. input "name:": name$(1:27) 
  141. print chr$(18)+name$ 
  142. print "length is";len(name$)
  143.  
  144. Run that program and type TEST as the
  145. name both times it asks. The first
  146. time it has a length of 4. The last
  147. time it has a length of 27 (the value
  148. was padded with spaces at the end).
  149. Printing it each time in reverse
  150. field shows how the (1:27) takes care
  151. of formatting problems for me!
  152.  
  153. Calculating the correct record length
  154. is also important when using random
  155. files. Use the maximum possible
  156. length as the length for the file. In
  157. this case I had 8 fields of 27
  158. characters, 1 field of 11 characters,
  159. and 1 field of 1 character. Since
  160. each field is a string, I also must
  161. add a 2 byte counter for each field.
  162. Thus 8*29 plus 13 plus 3 gives 248.
  163. The smallest record size I can use
  164. and be sure to hold all possible data
  165. is 248, which I set in the start'up
  166. procedure.
  167.  
  168. To calculate record length when using
  169. WRITE FILE remember these rules:
  170.  
  171. * A real or integer number uses 5
  172. bytes 
  173. * A string needs its maximum length
  174. PLUS 2 bytes for a length counter
  175.  
  176. Knowing how many records have been
  177. written is also important when using
  178. random files. If you attempt to read
  179. a record past the last existing one,
  180. an error occurs! A common way to keep
  181. track of the last record number is to
  182. WRITE it into the first record of the
  183. file:
  184.  
  185. write file 2,1: last'record
  186.  
  187. Last'record is a variable that holds
  188. the number of the last record written
  189. to the file. Now, each time you use
  190. that file, you can simply read the
  191. last record number from the file like
  192. this:
  193.  
  194. read file 2,1: last'record
  195.  
  196. The only side effect of this is that
  197. you cannot use the first record for
  198. regular data. Often, this is not a
  199. problem. For example, in our order
  200. processing system programs (running
  201. under IBM PC COMAL) COMAL Today
  202. subscribers are part of a random
  203. file, stored by their subscriber
  204. number. Since I use the first record
  205. to hold the last subscriber's number,
  206. I started my subscriber count with 2.
  207. Thus there is no subscriber number 1.
  208.  
  209. But in keeping track of Doctor Who
  210. shows, there is a show number 1.
  211. Since it can't be written into record
  212. number 1, we simply add 1 to the show
  213. number to give the record number
  214. (read this sentence twice - it makes
  215. sense). Thus show number 1 is stored
  216. in record number 2. Both read'record
  217. and write'record procedures do the
  218. record number conversion.
  219.  
  220. Another thing I try to do is keep my
  221. files closed as much as possible. On
  222. a Commodore disk, all files must be
  223. properly closed or they can't be
  224. opened later. So, I take precautions
  225. (in case of a power outage etc.) and
  226. keep the file closed when it is not
  227. directly being used. For example,
  228. while searching the file for matches,
  229. I use the procedure read'record
  230. directly, and don't close the file
  231. after each record is read. I only
  232. close the file after I find a match.
  233. However, when just getting
  234. information about one show, I have
  235. the procedure read'it which first
  236. opens the file, then reads the
  237. record, then closes the file. Thus
  238. the file is closed while I look at
  239. that record (and possibly edit it).
  240. Note that I always close the file
  241. after I write to it. Thus I only have
  242. one write'record procedure.
  243.